Multiple metal contamination from house paints: consequences of power sanding and paint scraping in New Orleans.

Power sanding exterior paint is a common practice during repainting of old houses in New Orleans, Louisiana, that triggers lead poisoning and releases more than Pb. In this study we quantified the Pb, zinc, cadmium, manganese, nickel, copper, cobalt, chromium, and vanadium in exterior paint samples collected from New Orleans homes (n = 31). We used interior dust wipes to compare two exterior house-painting projects. House 1 was measured in response to the plight of a family after a paint contractor power sanded all exterior paint from the weatherboards. The Pb content (approximately 130,000 microg Pb/g) was first realized when the family pet died; the children were hospitalized, the family was displaced, and cleanup costs were high. To determine the quantity of dust generated by power sanding and the benefits of reducing Pb-contaminated dust, we tested a case study house (house 2) for Pb (approximately 90,000 microg/g) before the project was started; the house was then dry scraped and the paint chips were collected. Although the hazards of Pb-based paints are well known, there are other problems as well, because other toxic metals exist in old paints. If house 2 had been power sanded to bare wood like house 1, the repainting project would have released as dust about 7.4 kg Pb, 3.5 kg Zn, 9.7 g Cd, 14.8 g Cu, 8.8 g Mn, 1.5 g Ni, 5.4 g Co, 2.4 g Cr, and 0.3 g V. The total tolerable daily intake (TTDI) for a child under 6 years of age is 6 microg Pb from all sources. Converting 7.4 kg Pb to this scale is vexing--more than 1 billion (10(9)) times the TTDI. Also for perspective, the one-time release of 7.4 x 10(9) microg of Pb dust from sanding compares to 50 x 10(9) microg of Pb dust emitted annually per 0.1 mile (0.16 km) from street traffic during the peak use of leaded gasoline. In this paper, we broaden the discussion to include an array of metals in paint and underscore the need and possibilities for curtailing the release of metal dust

Towards optimization-safe systems: analyzing the impact of undefined behavior

This paper studies an emerging class of software bugs called optimization-unstable code: code that is unexpectedly discarded by compiler optimizations due to undefined behavior in the program. Unstable code is present in many systems, including the Linux kernel and the Postgres database. The consequences of unstable code range from incorrect functionality to missing security checks. To reason about unstable code, this paper proposes a novel model, which views unstable code in terms of optimizations that leverage undefined behavior. Using this model, we introduce a new static checker called Stack that precisely identifies unstable code. Applying Stack to widely used systems has uncovered 160 new bugs that have been confirmed and fixed by developers.United States. Defense Advanced Research Projects Agency (DARPA Clean-slate design of Resilient, Adaptive, Secure Hosts (CRASH) program under contract #N66001-10-2-4089)National Science Foundation (U.S.) (NSF award CNS-1053143

Exact Gap Computation for Code Coverage Metrics in ISO-C

Test generation and test data selection are difficult tasks for model based testing. Tests for a program can be meld to a test suite. A lot of research is done to quantify the quality and improve a test suite. Code coverage metrics estimate the quality of a test suite. This quality is fine, if the code coverage value is high or 100%. Unfortunately it might be impossible to achieve 100% code coverage because of dead code for example. There is a gap between the feasible and theoretical maximal possible code coverage value. Our review of the research indicates, none of current research is concerned with exact gap computation. This paper presents a framework to compute such gaps exactly in an ISO-C compatible semantic and similar languages. We describe an efficient approximation of the gap in all the other cases. Thus, a tester can decide if more tests might be able or necessary to achieve better coverage.Comment: In Proceedings MBT 2012, arXiv:1202.582

A Loop-Aware Search Strategy for Automated Performance Analysis

Automated online search is a powerful technique for performance diagnosis. Such a search can change the types of experiments it performs while the program is running, making decisions based on live performance data. Previous research has addressed search speed and scaling searches to large codes and many nodes. This paper explores using a finer granularity for the bottlenecks that we locate in an automated online search, i.e., refining the search to bottlenecks localized to loops. The ability to insert and remove instrumentation on-the-fly means an online search can utilize fine-grain program structure in ways that are infeasible using other performance diagnosis techniques. We automatically detect loops in a program�s binary control flow graph and use this information to efficiently instrument loops. We implemented our new strategy in an existing automated online performance tool, Paradyn. Results for several sequential and parallel applications show that a loop-aware search strategy can increase bottleneck precision without compromising search time or cost

A simple, verified validator for software pipelining

International audienceSoftware pipelining is a loop optimization that overlaps the execution of several iterations of a loop to expose more instruction-level parallelism. It can result in first-class performances characteristics, but at the cost of significant obfuscation of the code, making this optimization difficult to test and debug. In this paper, we present a translation validation algorithm that uses symbolic evaluation to detect semantics discrepancies between a loop and its pipelined version. Our algorithm can be implemented simply and efficiently, is provably sound, and appears to be complete with respect to most modulo scheduling algorithms. A conclusion of this case study is that it is possible and effective to use symbolic evaluation to reason about loop transformations

From Specification to Optimisation: An Architecture for Optimisation of Java Bytecode

We present the architecture of the Rosser toolkit that allows optimisations to be specified in a domain specific language, then compiled and deployed towards optimising object programs. The optimisers generated by Rosser exploit model checking to apply dataflow analysis to programs to find optimising opportunities. The transformational language is derived from a formal basis and consequently can be proved sound. We validate the technique by comparing the application of optimisers generated by our system against hand-written optimisations using the Java based Scimark 2.0 benchmark